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EXECUTIVE  SUMMARY 

This  document  presents  a  model  which  depicts  the  flow  of  engineering  data  from 
the  contractor  source  to  the  government  user  destination.  The  government  Quality 
Assurance  (QA),  Pre-Acceptance  and  Final  Acceptance  processes  are  included  in 
the  model  for  application  to  a  variety  of  dam  procurement  requirements. 

The  process  model  is  of  modular  structure  and  provides  for  expansion  of  the 
functional  blocks  that  are  related  to  digital  data  acceptance.  This  organization  also 
provides  the  flexibility  for  additions  or  expansions  in  the  future  as  the  CALS 
standards  mature. 

The  product  data  model  addresses  engineering  drawing  data  with  emphasis  on 
Raster  Type  I.  Raster  Type  n  and  ICES  data  fit  the  model  within  the  guidelines 
of  CALS  and  the  model  can  be  expanded,  as  necessary,  to  apply  computer-assisted 
rfara  acceptance  techniques  to  Raster  Type  H  and  IGES  data  in  the  future. 

This  document  first  introduces  the  model,  the  methodology  used,  and  the  CALS 
documentation  types  addressed.  The  model  is  then  presented  in  terms  of  product 
Hata  procurement  as  an  overview  of  contractor  and  government  interactions.  The 
model  next  expands  the  contractor  function  to  depict  the  Product  Data  Generation 
processes.  The  government  functions  are  also  expanded  to  show  the  Product  Data 
Acceptance  processes  at  the  contractor  site.  Finally  the  model  expands  the 
common  Data  Pre-Acceptance  fiinction  from  each  of  these  processes  to  show  how 
computer-assisted  Data  Acceptance  techniques  can  be  applied. 

A  description  of  the  application  of  computer-assisted  techniques  to  the  Pre- 
Acceptance  of  engineering  data  is  provided.  The  model  shows  how  the  image 
quality  and  identification  data  (ID)  can  be  analyzed  to  produce  accept/reject 
reports  for  final  analysis  at  an  image  workstation.  Computer-Assisted  Data 
Acceptance  will  greatly  reduce  the  labor  intensive  viewing  of  digital  data  at  an 
image  workstation.  The  model  identifies  Pre-Acceptance  modules  at  the 
contractor  site  and  the  government  site  where  the  Computer-Assisted  Data 
Acceptance  Procedures  can  be  applied. 

The  acceptance  of  large  amounts  of  digital  data  dictates  the  use  of  computer- 
assisted  techniques  to  reduce  the  time  consuming  QA  of  the  digital  data.  In  order 
to  predict  performance,  it  will  be  necessary  to  determine  the  effectiveness  and  the 
extent  of  applicability  of  computer-assisted  techniques.  This  can  best  be  done  by 
simulating  key  activities  depicted  in  the  model  and  by  extensive  testing  of 
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applicable  computer-assisted  techniques.  This  testing  is  planned  for  the  near 
future. 
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LO  INTRODUCTION 

The  acquisition,  acceptance,  storage,  management,  distribution  and  use  of  data  for 
the  logistic  support  of  weapon  systems  has  long  been  a  challenge  for  the  member 
agencies  of  the  Department  of  Defense  (DoD).  One  of  the  biggest  problems  is 
fhar  of  obtaining  and  maintaining  quality  data.  This  problem  has  been  recognized 
for  many  years  by  the  DoD  agencies  and  has  been  addressed  by  improving  the 
data  storage  medium  in  terms  of  resolution,  durability,  and  storage  density. 
Micrographic  media  such  as  aperture  cards  were  introduced  to  successfully  reduce 
the  data  storage  and  distribution  problems  associated  with  the  use  of  hard  copy. 

As  weapon  system  technology  advanced  and  complexity  increased,  the 
requirements  for  more  support  data  increased.  It  is  reponed  that  there  are  now 
some  200  million  source  aperture  cards  in  use  by  the  DoD  agencies.  The  manual 
storage,  indexing,  and  management  of  the  growing  data  base  have  a^Jn  become  a 
problem.  More  importandy,  the  quality  of  the  data  has  suffered  due  to  increased 
handling  and  duplication  of  the  aperture  cards.  Technological  advances  of  the  last 
two  decades  in  processing  speed  and  power,  mass  storage  speed  and  capacity, 
image  processing,  image  scanners  and  image  software  have  provided  economic 
means  of  solving  or  at  least  minimizing  many  of  these  problems. 

The  DoD  authorized  the  procurement  of  repository  image  management  systems 
in  the  early  1980s  to  apply  such  technological  advances  toward  the  solution  of  the 
data  management  problems.  A  joint  Army/Air  Force  procurement  of  the  Digital 
Storage  and  Retrieval  Engineering  Data  System  (DSREDS)/Engineering  Data 
Computer  Assisted  Retrieval  System  (EDGARS)  resulted  in  the  installation  of  12 
data  repository  sites.  In  late  1989,  the  Navy  installed  its  tint  Engineering  Data 
Management  Information  and  Control  System  (EDMICS)  repository  system. 

DSREDS/EDCARS  and  now  EDMICS  are  ail  actively  involved  in  the  conversion 
of  the  aperture  card  data  for  active  weapon  systems  to  digital  image  data  on  mass 
storage  media  so  that  they  can  be  ready  for  full  production  operations. 

At  least  one  problem  still  exists.  How  does  the  government  know  that  the 
convened  digital  image  data  is  of  sufficient  quality  to  store  in  their  repositories? 
The  government  has  qualified  personnel  that  know  how  to  view  micrographic  data 
for  acceptance  but  they  have  limited  experience  in  the  acceptance  of  digital  data 
in  large  volume.  Presently,  this  is  accomplished  by  viewing  each  image  on  a  high 
resolution  graphic  workstation.  This  has  proven  to  be  labor-intensive,  time 
consuming  and  error-prone.  The  acceptance  of  data  therefore  requires  a  high  use 
of  the  repository  resources  which  adversely  impacts  the  repositories’  prime 
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mission  which  is  to  store  and  distribute  the  data.  When  digital  data  is  imported 
to  the  DSREDS/EDCARS/EDMICS  systems,better  means  must  be  used  to  QA  and 
accept  the  digital  data. 

A  review  of  the  existing  DSREDS/EDCARS  and  EDMICS  procedures  was  made 
and  a  set  of  manual  data  acceptance  procedures,  using  the  repository  system,  was 
developed  and  has  been  field  tested  at  an  Army  DSREDS  site.  A  review  of  the 
manual  procedures  and  testing  in  the  field  has  pointed  up  the  need  to  minimize 
the  manual- visual  QA  of  each  image  at  die  repository.  To  accomplish  this,  there 
is  a  need  to  develop  computer-assisted  data  acceptance  procedures  and  to 
recommend  alternatives  for  the  implementation  of  the  procedures  (i.e., contractor 
site,  user  site  or  both). 

DoD  recognized  that  the  problems  of  data  quality  and  the  distriburion  of  the  data 
could  best  be  solved  by  developing  standards  for  the  development  and  distribution 
of  data  in  an  electronic  format.  The  Computer-Aided  Acquisition  and  Logistic 
Support  (CALS)  initiative  introduced  in  1985  provided  the  basis  of  obtaining 
quality  product  and  technical  publication  data  in  standard  formats  and  on  standard 
media.  Industry  is  cooperating  with  the  DoD  in  the  development  and  testing  of 
these  standards.  The  Army  CALS  Test  Bed  was  tasked  to  develop  and  test 
manual  data  acceptance  procedures  applicable  to  the  existing  DSREDS/EDCARS 
data  repository  systems.  As  part  of  the  infrastructure  modernization  effort,  the 
CALS  policy  office  has  directed  the  CALS  Test  Network  (CTN)  to  develop 
procedures  for  the  acceptance  of  product  and  technical  publication  data  in  CALS- 
compliant  format 

One  should  not  underestimate  the  difficulty  of  developing  a  common  set  of  data 
acceptance  procedures  for  the  various  tri-service  data  repository  sites.  The  sites 
observe  different  operating  procedures,  deal  with  different  data  types,  data  formats, 
identification  data,  and  use  different  hardware/softwarc  platforms. 

It  became  apparent  that  there  was  a  need  to  develop  a  model  as  a  formal  means 
of  presenting  an  overview  of  the  salient  attributes  of  the  repositories’  requirements 
for  the  acceptance  of  data  from  its  genererion  to  its  final  destination.  The  model 
would  be  the  basis  for  developing  data  acceptance  procedures  for  engineering 
drawing  raster  and  IGH3  data.  The  model  would  be  of  such  modularity  that  it  can 
be  expanded  in  the  future  to  include  additional  product  data  types  or  to  track  the 
evolution  of  CALS  standards. 
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2.0  PURPOSE 

This  document  presents  a  model  which  depicts  the  flow  of  engineering  drawing 
data  from  the  contractor  source  to  the  user  destinadon. 

The  model  describes,  at  a  high  level,  the  processing  and  databases  involved  in  the 
acceptance  of  CALS-compliant  digital  engineering  data  by  a  government  agency. 
The  model  is  intended  to  be  used  for  the  development  of  manual  and  computer- 
assisted  data  acceptance  procedures  for  use  by  the  tri-services. 


3.0  SCOPE 

The  model  describes  the  major  acdvities  required  to  perform  data  acceptance  of 
digital  engineering  data.  Engineering  data  includes  engineering  drawings  and 
associated  lists.  The  model  encompasses  the  entire  contract  period  from  contract 
award  to  the  final  acceptance  and  storage  of  data  in  an  engineering  drawing 
repository.  It  also  includes  the  return  of  rejected  contract  deliverables  to  the 
contractor.  The  model  also  describes  the  government  agency’s  activities  in  the 
process;  the  contractor’s  activities  are  shown  only  to  the  extent  that  they  relate 
directly  to  digital  data  acceptance.  Further  details  regarding  the  contractor’s 
activities  are  omitted. 

MIL-STD-1840A  defines  the  product  data  file  as  engineering  drawing  data, 
application  data,  and  numerical  control  data.  However,  the  model  addresses  only 
engineering  data.  Application  data  and  numerical  control  data  can  be  addressed  in 
the  future  when  MIL-STD-I840A  specifications  are  further  developed.  Both  raster 
and  IGES  types  of  engineering  data  are  encompassed  in  the  model.  However, 
raster  data  is  emphasi:red  because  it  is  ctarently  the  predominant  data  type  stored 
in  the  repositories. 
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4.0  APPROACH 

Procedures  and  techniques  used  by  selected  government-owned  digital  data 
repositories  were  obtained  and  tmalyzed.  The  procedures  and  techniques  were 
broken  down  into  fundamental  processes  at-d  databases  to  provide  a  baseline  for 
the  development  of  a  model  Existing  and  proposed  computer-assisted  techniques 
and  tools  for  dealing  with  digital  image  data  were  researched. 

Modeling  methodologies,  techniques,  and  tools  available  to  develop  data  models 
were  reviewed.  Tlie  model  is  documented  with  the  use  of  process  flow  diagrams. 
A  CASE  tool  was  used  to  assist  in  preparing  the  model  for  preseniarion.  The  Gane 
&  Sarson  methodology  was  selected  for  the  development  of  the  process  flow 
diagrams. 


4.1 


The  model  is  Olustrated  as  a  hierarchy  of  Gane  &  Sarson  process  flow  diagrams. 
The  process  flow  diagram  describes  a  breakdown  of  an  overall  procedure.  It  shows 
data  stores,  processes  which  operam  on  them,  and  the  data  flow  which  supports 
die  processing.  Tlie  symbols  used  in  die  process  flow  diagrams  are  shown  in  the 
legend  in  Figure  1. 

A  process  is  shown  as  a  rectangular  figure  labeled  with  the  letter  "P"  with  rounded 
comers.  A  process  denotes  a  distinct  procedure,  step,  or  other  breakdown  of  a 
larger  process.  A  data  store  is  a  rectangular  figure  labeled  with  the  letter  "D" 
which  is  open  on  the  right-hand  side.  A  data  flow  is  shown  as  a  directed  line 
segment  which  is  connected  to  the  origin  of  the  data  and  the  destinarion  of  the 
data.  A  data  flow  implies  that  the  data  exists  temporarily  while  a  data  store 
implies  some  permanence. 

Data  stores  are  shown  in  the  disa-'am  v-'idiCut  regard  to  the  storage  medium;  data 
may  be  digital  data,  paper  dais,  verbal  data,-  etc,.  Data  flows  are  shown  in  the 
diagram  widioat  regard  to  the  naasfer  medium:;  data  transfer  may  be  via  magnetic 
media,  teiecommimicarions,  mail,  spoken  word,  etc.  Similarly,  processing  is  shown 
without  XBgajri.  to  the  mesns  by  which  it  i.s  accomplished;  processing  may  be 
computer  presc:essing,  madiinc  proces-sing,  manual  processing,  etc. 

A  process  flow  diagram  shows  all  data  stores  and  processes  and  all  possible  data 
flows.  For  any  possible  scenario,  a  subset  of  ail  processes  and  data  may  be 
applicable.  Tlie  diagram  does  not  show  the  sequence  of  processes  since  the 
sequence  may  vary  for  each  possible  scenario. 
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Figure  1  -  Gane  &  Sarson  Methodology  Symbol  Legend 
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4J.  Model 


The  digital  data  acceptance  inocksi  describes  funcrions  within  the  product  t^ta 
procurement  process  for  engineering  drawing  data.  The  model  depicted  provides 
an  overview  of  die  flow  of  data  from  die  contractor’s  development  to  the  final 

acceptance  by  the  government  at  the  user’s  site. 

Emphasis  is  placed  on  the  acceptance  of  the  digital  data  at  vmous  stages  in  the 
development  atid  delivery  of  die  data  on  various  media.  The  intent  is  to  provide 
a  model  that  will  provide  a  brmd  high  level  overview  of  where  the  data 
acceptance  can  be  implemented.  The  model  attempts  to  provide  a  number  o 
opdons  for  application  of  data  acceptance  procedures.  The  resultant  digital  data 
acceptance  procedures  therefore  may  be  implemented  in  a  manner  to  meet  me 
parricuiar  procurement  requirements  of  data  as  specified  in  the  contract.  For 
example,  a  major  weapon  system  procurement  may  require  extensive  reviews  of 
the  product  data.  This  may  include  pre- acceptance  of  data  at  the  contractor  site 
by  using  computer- assisted  data  acceptance  software  resi(^g  on  the  contractors 
system  or  residing  on  goveinrncnt  furnished,  stand-alone  image  platfonTi(s).  n 
the  other  hand,  this  same  computer-assisted  data  acceptance  software  may  be 
utilized  only  at  the  user  site  for  low-volume  data  procurement  and  acceptance  of 
data  associated  with  engineering  changes.. 


The  model  is  no£  dependent  on  paiticular  software  or  hardware  platforms  to 
perform  the  funcrions.  For  example,  software  providing  computer-assisted 
techniques  used  in  pre -acceptance  can  be  installed  on  existing  hardware  or  on  new 
hardware  purchased  3pecific3.ny  to  peitorrn  the  function. 

The  model  addresses  a  variety  of  transfer  media  by  considering  data  in  terms  of 
files  which  have  a  logical  scractme  'vivicn  is  independent  of  the  physical  medium 
or  file 


uxiCt:ioa.s Ocxitic  in  terms  of  the  responsibility  for 
or  'vixarnpit- .  axtv  functions  which  arc  performed  by  a 


The  app.!i,c.-t:on 

performing 

contractor  con  also  be  performed  by  a  subcontractor  if  the  subcontractor  has  the 
resources  to  do  s 


The  Data  Pt'::- ■Nccepimit.s  bsock:.' 

Acceptance,  to  tvfturibc  dss  c 


expanded  in  section  8.0,  Data  Pre- 
techniques  in  greater  detail. 


6 


CTN  Test  Report 
91-026 


Model  »  Engineering  Data 


4^  Digital  Documentation  Types 

The  relationship  among  the  various  types  of  digital  documentation  which  are 
defined  in  MIL-STD-1840A  is  shown  in  Figure  2.  The  digital  documentation  types 
addressed  in  the  model  are  depicted  by  solid  rectangles.  Those  not  addressed  are 
depicted  by  dashed  rectangles. 

Each  type  of  data  is  shown  with  the  section  in  ME.-STD-1840A  which  defines  it 
or  references  it  Each  type  of  data  which  is  referenced  but  defined  elsewhere  is 
shown  with  the  document  and  section  which  defines  it. 

Digital  Documentation.  This  includes  all  data  types  described  by  MIL-STD- 
1840A.  It  is  subdivided  into  Product  Data  and  Technical  Publications. 

Product  Data.  Product  Data  consists  of  Engineering  Drawing  Data,  Application 
Data,  or  Numerical  Control  Data. 

Technical  Publications.  Technical  Publications  consist  of  text  and  associated 
illustradons.  This  type  of  data  and  its  subdivisions  are  not  addressed  in  this 
document 

Engineering  Data.  Engineering  data  consists  of  engineering  drawing  data, 
associated  lists,  and  other  related  documents. 

Engineering  Drawing  Data.  This  consists  of  digital  representations  of  engineering 
drawings.  It  is  subdivided  into  ICES  Data  and  Raster  Data. 

Application  Data.  Electrical/electronic  application  data  files  are  Class  III 
application  data  subsets  as  specified  by  MIL-D-28000.  This  type  of  data  and  its 
subdivisions  are  not  addressed  in  this  document. 

Numerical  Control  Data.  Numerical  control  data  files  are  Class  IV  application  data 
subsets  as  specified  by  MIL-D-28000.  This  type  of  data  and  its  subdivisions  are 
not  addressed  in  this  document. 

IGES  Data.  IGES  engineering  drawing  data  files  are  Class  II  application  data 
subsets  as  specified  by  MIL-D-28000.  They  are  vector  representations  of 
engineering  drawing  data. 

Raster  Data.  Raster  engineering  drawing  data  files  are  described  by  MIL-R-28002. 
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Fi  gure  2  -  Digital  Documentation  Types 
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Type  I  Daa.  Type  I  Raster  Data  consists  of  untiled  engineering  drawings. 
Type  H  Data.  Type  II  Raster  Data  consists  of  riled  engineering  drawings. 
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5.0  PRODUCT  DATA  PROCURES'fENT  OVERVIEW 

The  Product  Data  Procurement  process  describes  an  overview  of  the  major 
activities  and  exchange  of  materials  between  a  government  agency  and  a 
contractor.  Product  Data  Procurement  is  shown  in  Figure  3. 

The  process  begins  with  a  Contract  Award  for  the  procurement  of  Product  Data. 
This  is  followed  by  Contractor  Validation  which  ensures  that  the  contractor  has 
a  government-approved  quality  assurance  program  in  place  and  has  the  capability 
to  produce  the  deliverables  specified  by  the  contract. 

Product  Data  Generation  can  start  after  contractor  Validation  is  completed.  This 
is  a  major  activity  which  produces  contract  deliverables  that  will  be  sent  to  the 
goveniment  site. 

Product  Data  Acceptance  is  performed  for  all  product  data  contract  deliverables 
sent  by  the  contractor.  Product  data  acceptance  can  be  a  multi-stage  process  in 
which  pre-acceptance  is  performed  at  the  contractor  site  or  government  site  and 
final  acceptance  is  petfotmed  at  the  government  sits.  Product  Data  which  is 
accepted  is  stored  in  the  Engineering  Drawing  Repository.  Product  Data  which 
is  rejected  is  returned  to  the  contractor  for  resolution. 

The  deliverable  package  will  contain  the  deliverable  files  as  specified  in  the 
contract  and  a  data  list  created  by  the  contractor.  It  is  recommended  that  both  be 
delivered  in  digital  format  and  on  media  specified  by  the  contract.  The  media 
may  be  magnetic  tape,  optical  di.sk,  floppy  disk,  telecommunications,  or  other 
media  to  be  determined  in  the  future. 

The  deliverable  files  will  be  cl3.ssified  in  compliance  v/ith  MIL-STD-1840A;  a 
volume  will  contain  one  or  more  documents,  a  document  will  consist  of  one  or 
more  file  ses,  a  file  set  will  consist  of  one  declaration  fils  and  one  or  more  data 
files,  a  data  file  will  contain  the  digital  representadon  of  one  engineering  drawing, 
and  a  data  file  will  consist  of  a  header  record  and  one  or  more  data  records.  Note 
that  an  engineering  drawing  may  be  one  of  several  sheets  for  a  drawing  number; 
each  sheet  will  be  stored  in  a  separate  data  file. 


In  the  C3SS  of  physical  media,  the  deliverable  package  will  consist  of  the 
deliverable  files  on  the  media  in  a  properly  labeled  and  sealed  container  which  is 
shipped  via  the  freight  carrier  specified  in  the  contract.  In  the  case  of 
telecommunications  media,  the  deliverable  package  will  consist  of  a  set  of 
deliverable  files  which  are  cran.smitted  from  the  contractor’s  system  to  the 
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Government  Site 


Figure  3  -  Product  Data  Procurement 
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govenmient  agency  system.  The  contract  will  specify  that  contract  deliverables 
which  do  not  comply  with  the  requirements  of  the  contract  will  be  returned  to  the 
contractor. 


Each  of  the  Product  Data  Procurement  funcrions  are  described  below; 

5.1  Contract  Award  (PI) 

The  process  begins  with  the  award  of  a  contract  by  a  government  agency  to  a 
contractor  for  the  purchase  of  weapon  system  data.  The  contract  includes 
provisions  for  the  purchase  of  production  engineering  drawings  and  defines  the 
criteria  for  data  acceptance  and  rejection.  The  contract  issued  by  the  government 
agency  will  include  the  Statement  of  Work  (SOW),  Contract  Data  Requirements 
List  (CDRL),  and  Data  Item  Description  (DDD).  It  is  used  by  the  government 
agency  for  contractor  validation,  by  the  contractor  for  product  data  generation,  and 
by  the  government  agency  for  product  data  acceptance. 

5.2  Contractor  Validation  (P2) 

The  contractor  is  subjected  to  a  contractor  validation  process  by  the  government 
agency.  This  determines  that  the  contractor  has  a  quality  assurance  program  and 
resources  in  place  and  has  demonstrated  the  capability  to  produce  digital  data  in 
CALS -compliant  format  on  media  specified  in  the  contract.  The  contractor  will 
provide  documentation  of  a  government-approved  quality  assurance  program  to 
a  government  representative.  The  government  will  verify  that  the  contractor  has 
the  capability  to  provide  CALS-compliant  data  on  the  contract-specified  media. 
In  lieu  of  this  previous  government  verification,  the  contractor  will  supply  a 
sample  data  deliverable  which  will  be  subjected  to  format  verification  to  verify 
that  the  deliverafala  is  in  CALS-compliant  formaL 

5.3  Product  Data  Generation  (PI) 

Upon  completion  of  Contractor  Validation  the  contractor  will  produce  a 
deliverable  package  of  Product  Data  according  to  the  terms  of  the  contract. 


A  key  part  of  Product  Data  Generation  is  the  pre-acceptance  of  product  data  at  the 
contractor  site  by  a  quaiifisri  government  representative.  As  part  of  the  contract. 
Product  Data  Generation  has  provisions  for  receiving  returned  contract 
deliverables  from  the  government  agency.  These  deliverables  may  have  been 
rejected  due  to  a  variety  of  reasons:  improper  shipping,  incorrect  data,  poor  quality 
data,  etc.  See  section  6.0,  Product  Data  Generation,  for  additional  details. 
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5.4  Product  Data  Acceptance  (P4) 

The  government  agency  is  notified  that  a  package  of  contract  deliverables  from 
the  contractor  is  ready  for  Pre-Acceptance. 

A  key  part  of  the  product  data  acceptance  process  is  the  pre-acceptance  of  product 
data.  The  government  agency  accepts  the  data  in  part  or  in  whole  and/or  rejects 
it  in  part  or  in  whole  based  on  its  compliance  or  non-compliance  with  the  terms 
of  the  contract.  Accepted  data  is  stored  in  ±e  Engineering  Data  Repository. 
Rejected  data  is  returned  to  the  contractor  in  the  form  of  returned  contract 
deliverables.  See  section  7.0,  Product  Data  Acceptance,  for  additional  details. 
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6.0  PRODUCT  DATA  GENERATION 

Prcxiuct  Dam  Genemoon,  as  shown  in  the  diagram  of  Figure  4,  consists  of  the 
functions  requited  to  generate,  QA  and  pre -accept  product  data  at  the  contractor’s 
site.  It  should  be  noted  that  the  term  "product  data"  is  used  to  represent  Raster 
Type  I,  Raster  Type  n,  or  IGES  data.  Each  of  ±e  functional  blocks  are 
sequentially  numbered.  (P3.1,  P3.2,  etc.)  to  assist  in  following  the  process  flow. 
A  number  of  common  input  and  output  items  are  shown  with  arrows.  These 
include.  Contract,  Product  Dam,  Rejected  Product  Data  and  Data  List. 

Data  may  be  delivered  and  rejected  data  returned  on  physical  media,  such  as 
magnedc  tape  or  optical  disk,  or  via  telecommunication.  The  rejected  physical 
media  or  files  may  be  received  and  stored  in  a  manner  consistent  with  the  method 
of  transmission. 

Product  Data  Generation  is  initiated  upon  receipt  of  the  contract  and  after  the 
Contractor  Validation  has  been  completed.  The  contractor  will  have  completed 
the  development  of  the  R&D  dra'vings,  in-process  technical  reviews  and  now  will 
generate  the  production-level  product  data. 

As  noted  in  Figure  4,  the  contractor  will  create  a  source  database  of  product  data 
and  perform  100%  quality  assurance  by  visual  inspection.  Sampling  Oa  of  source 
data  by  a  government  representative  will  be  conducted  if  specified  in  the  contract. 

The  conoractor  will  create  deliverable  files  in  CALS-compliant  format  and  a  data 
list  of  tiie  deliverable  files.  The  government  will  then  perform  on-site  pre¬ 
acceptance  of  the  data  as  specified  in  the  contract.  Figure  4  shows  that  this  can 
be  done  from  the  CAlJS-fotmatted  Deliverable  Files,  eidier  in  a  database  or  in  the 
deliverable  package. 

The  following  section  provides  a  more  comprehensive  description  of  each  of  the 
ftinctional  blocLs  v/ithin  the  Product  Data  Generaticn.  process. 


6.1  Generate  Product  Data  (P3.1) 

This  funcriona.1  block  includes  die  total  development  starting  at  contract  award. 
The  prime  and  many  subcontractors  may  be  involved  in  the  development  as  wcil 
as  the  government  in  the  technical  review  process.  For  the  purpose  of  this  model 
it  is  assumed  that  tiiese  have  been  completed  and  that  final  production  engineering 
drawings  (Level  HI)  are  in  preparation. 
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The  product  data,  may  come  frqm  a  variety  of  sources,  especially  for  a  major 
weapon  system  prc^urement  The  prime  conmctor  may  develop  the  engineering 
documentation  on  CAD/CAE/CAM  systems,  manual  drafting,  or  a  combination  of 
both.  Subconfflactots  may  deliver  data  via  hard  copy  or  aperture  cards.  This  data 
must  be  converted  and  delivered  in  CAI.«S-'Compli3nt  format.  Regardless  of  the 
native  format  of  the  source,  the  quality  of  the  product  data  must  be  maintained 
during  these  conversion  processes. 

The  Generate  Product  Data  functional  block  of  Figure  4  shows  a  number  of 
inputs.  The  Contract  shown  is,  of  course,  key  to  defining  the  requirements  for  the 
development  of  new  data  and  handling  of  rejected  data  as  well  as  defining  the 
criteria  for  the  acceptance  of  data  at  the  contractor  and  government  site.  The 
product  data  may  be  rejected  at  a  number  of  places  during  the  development  as 
shown  in  Figure  4.  At  either  the  contractor^  site  or  the  government  site,  product 
data  files  or  identification  data  may  be  rejected  At  the  government  site,  quality 
and  identification  data  errors  may  result  in  returning  the  entire  deliverable 
package,  one  or  more  magnetic  tape  or  opticai  disk  volumes,  or  even  a  data  list 
which  identifies  the  rejected  drawings  with  description  of  the  type  errors  by 
drawing  number  or  some  other  identificadon.  These  rejected  files,  media,  or  data 
lists  will  then  be  regenerated.  Tie  corrected  data  may  be  reviewed  again  by  the 
on-site  government  representarive  or  for  small  quandnes  may  also  be  returned  to 
the  user  for  review  and  acceptance.  This  data  must  be  corrected  and  is  therefore 
shown  as  inputs  to  this  functional  block. 

The  contractor  generates  new  data  from  the  various  information  data  sources  (hard 
copy,  aperture  cards,  CAD)  and  convens  and  stores  the  data,  in  native  format,  on 
his  Source  Product  Dam  database. 

6.2  100%  Quality  A^ssisrancs  (P3.2) 

As  required  by  the  contract,  the  conoracior  performs  100%  quality  assurance  on 
tlie  data  in  the  coniracror’s  own  source  product  data  base.  This  is  done  before  any 
deliverables  are  gensraied.  Any  product  data  rejected  by  the  contractor  is  re¬ 
generated  by  Product  Data  Generation  and  replaced  in  the  source  data  base.  The 
contractor  will  certify  that  100%  QA  has  been  completed.  The  government 
tepressntaD,ve  will  verify  that  die  contractor  has  performed  100%  quality  assurance 
by  reviewing  ths  contractors  cerTificarion  documentation  as  well  as  QA  records 
when  required. 
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6^  Sampling  Quality  Assurance  (P3J) 

The  qualified  government  representadve  may  perfonn  sampling  quality  assurance 
on  the  data  in  the  conoractor’s  source  data  base  if  the  contract  specifies.  The 
sampling  will  require  use  of  the  contiactofs  image  workstadon  or  a  compadbie 
workstadon  if  remote  access  to  the  data  base  is  a  contract  requirement.  The 
implementadon  of  this  step  is  contract  dependent  and  may  be  more  appropriate  for 
major  weapon  system  procurement.  The  sampling  QA  may  be  performed  during 
the  process  of  generating  the  data  or  after  a  defined  file  set  of  product  data  has 
been  completed  by  the  contractor  and  prior  to  conversion  of  the  data  to  CALS- 
compliant  format. 

Any  files  rejected  by  the  govenunent  representadve 's  sampling  QA  are  re¬ 
generated  at  this  stage  by  the  Product  Data  Generadon  funcdon  and  replaced  in 
the  source  data  base  for  QA  by  the  government  representadve  prior  to  generadon 
of  the  deliverable  CALS-compliant  files. 

6.4  Generate  Deliverable  Files  (P3.4) 

The  contractor  generates  the  deliverable  files  in  CALS-compliant  format  as 
required  by  the  contract  and  a  separate  data  list  file  on  the  deliverable  medium 
specified  by  the  comracL  The  separate  data  list  is  created  to  itemize  the 
deliverables  generated  and  to  be  used  by  the  government  agency  to  track  the  data 
during  the  acceptance  process. 

This  funcdon  also  encompasses  the  re-generadon  of  deliverable  files  which  are 
rejected  by  the  format  verificadon  procedure  during  pre-acceptance.  The 
deliverable  files  may  have  been  rejected  at  one  or  both  of  two  points  in  the 
product  data  procurement  process.  They  may  have  been  rejected  by  the 
government  representadve ’s  pre-acceptance  at  the  contractor  site  or  they  may  have  | 
been  returned  to  the  contractor  after  being  rejected  at  the  government  user  site. 

6.5  Data  Pre-Acceptance  (P3.5) 

This  functional  block  is  the  recommended  area  for  the  application  of  computer- 
assisted  techniques.  Application  software  will  apply  these  techniques  to  inspect 
image  quality  and  identification  data  quality  of  the  deliverable  files.  Visual 
sampling  will  then  be  performed  on  the  deliverable  files.  Pre-acceptance  may  be 
performed  on  the  deliverable  media  of  the  Deliverable  Package  or  on  the 
Deliverable  Files  Database.  Pre-acceptance  may  be  performed  on  a  stand-alone 
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workstation  or  on  an  existing  system.  Equipment  may  be  contractor-furnished  or 
government-furnished. 

Product  data  rejeaed  at  this  stage  due  to  quality  will  be  re-generated,  convened 
and  returned  to  the  deliverable  data  base  for  review.  Idendiicadon  data  and 
format  rejecdons  will  also  be  corrected  prior  to  delivoy.  The  media  format 
veiificadon  applicadon  software  can  only  be  applied  if  the  deliverable  media  is 
checked  by  the  government  at  this  time. 

If  the  data  passes  pre-acceptance  via  CALS  Deliverable  Files  review  then  the 
contractor  may  prepare  the  data  for  delivery  by  the  Generate  Deliverable  Package 
foncdon.  If  pre-acceptance  was  conducted  on  the  deliverable  media,  all  that 
would  be  required  is  the  packaging  of  the  media  for  shipment.  See  secdon  8.0, 
Data  Pre-Acceptance,  for  addidonal  details. 

6.6  Generate  Deliverable  Package  (P3.6) 

Upon  sadsfactory  compledon  of  the  government  performed  pre-acceptance,  the 
data  may  be  prepared  for  delivery.  The  extent  of  the  preparadon  depends  on 
whether  the  pre-acceptance  was  performed  on  the  deliverable  media  or  on  the 
CALS-compliant  Deliverable  Files  database. 

The  contractor  will  prepare  the  contract  defined  documentadon  to  be  delivered 
with  the  data  and  the  data  list.  The  data  list  may  be  hard  copy  only,  in  electronic 
format  or  both.  If  in  electronic  format  it  is  recommended  that  this  be  on  magnetic 
tape  inidally  and  perhaps  floppy  disk  in  the  future. 

If  the  government  has  performed  pre- acceptance  on  the  deliverable  files  then  the 
contractor  will  package,  the  government  'Anil  inspect  and  it  will  be  shipped  to  the 
government  user  site. 

One  of  the  inputs  to  the  Generate  Deliverable  Package  funcdonal  block  is 
Rejected  Package.  If  a  previously  delivered  package  was  returned  due  to  damage, 
then  it  may  be  repackaged  and  reshipped. 

6.7  Receive  (Accept)  Returned  Deliverables  (P3.7) 

The  contractor  receives  returned  product  data  from  the  government  site  in  part  or 
in  whole.  The  returned  deliverable  may  be  the  entire  package  or  one  or  more  files 
of  data.  The  contract-specified  rejection  criteria  may  include  poor  image  quality. 
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poor  or  inaccurate  identification  data,  improper  media  or  data  format,  missing  or 
inaccurate  data  list,  or  improper  packaging. 

The  returned  deliverable  is  re-generated  with  the  appropriate  functional  block.  A 
returned  deliverable  package  is  le-generated  by  the  Generate  Deliverable  Package 
functional  block  while  files  returned  due  to  rejected  format  may  be  re-generated 
by  the  Generate  Deliverable  Files  functional  block.  Product  data  returned  due  to 
poor  image  quality  will  be  regenerated  by  the  Generate  Product  Data  functional 
block.  T^e  Returned  Contract  Deliverables  may  take  the  form  of  an  electronic 
data  list  which  identifies  the  rejected  data  by  drawing  number  and  describes  the 
reason  for  rejection.  Support  hard  copy  may  be  a  contract  requirement.  The 
contractor  can  view  his  CALS-compliant  Deliverable  Files  database  or  look  at  the 
rejected  data  by  drawing  number  in  his  native  Source  Database.  Regeneration  can 
then  commence  from  this  point. 
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7,0  PRODUCT  DATA  ACCEPTANCE 

The  Product  Data  Acceptance  process  of  Figure  5  shows  the  data  flow  and 
functions  required  to  receive,  accept,  reject,  tmnslare  and  store  product  data  at  the 
fovemment  aser  site.  Again,  "Product  Data"  is  used  to  represent  Raster  Type  I, 
Raster  Type  n,  or  IGES  data. 

Each  of  the  ftmctional  blocks  is  sequentially  numbered  (P4.1J*4.2,  etc)  to  assist 
in  foUowing  the  flow  for  product  (feta  acceptance  at  the  government  user  site. 
The  input  md  output  items,  depicted  by  arrows,  include  Contract,  Data  List, 
Product  Data,  and  Rejected  Product  Daa. 

Data  may  be  received  from  the  contractor  and  rejected  data  returned  to  the 
contractor  on  physical  media  or  via  telecommunication.  Date  transmitted  by 
telecommunications  will  be  stored  temporarily. 

As  shown  in  Figitre  5,  die  data  package,  which  includes  the  data  list,  will  be 
accepted  in  accordance  with  the  contract  requirements  and  the  delivered  files  will 
be  temporarily  stored  m  a  Deliverable  Files  database.  At  this  point  the  data  may 
undergo  pre-acceptance  and  upon  acceptance  may  then  be  translated  fr’om  the 
CALS  format  to  the  repository  native  format.  The  pre-acceptance  step  is  an 
optional  step  that  is  not  recommended  if  full  contractor  on-site  pre-acceptance  has 
been  performed.  If  Daa  Pre-acceptance  has  been  performed,  it  is  recommended 
that  the  government  only  conduct  sampling  QA  of  the  product  daa  for  Final 
Acceptance.  This  should  be  a  contract  defined  option  and  will  be  guided  by  the 
individual  contractor  performance  hLstory.  Upon  acceptance,  the  data  will  be 
permanently  stored  within  the  government  engineering  (drawing  repository. 

The  following  sections  provide  a  more  comprehensive  description  of  each  of  the 
functional  blocks  within  the  Product  Dam  Acceptance  process  flow  shown  in 
Figure  5. 


7.1  Receive  (Accept)  Package  (P4.1) 

The  concactor  site  pre  acccr^tance  has  been  completed  and  the  contractor 
transports  the  deliverable  package  in  ths  contract  defined  media  to  the  government 
user  site.  The  government  inspeem  the  deliverable  package  in  accordance  with  the 
contract  requirements.  Acceptance  of  die  delivered  data  package  via 
telecommunication  means  will  require,  as  a  minimum,  techniques  for  validating 
that  the  data  information  sent  was  received.  Acceptance  of  the  physical  package 
requires  that  the  physical  package  complies  with  the  contract  packaging  and 
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Government  Site 


Figure  5  -  Product  Data  Acceptance 
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shipping  requirements.  The  deliverable  files  and  data  list  may  now  be  made 
available  to  the  government  agency  or  group  responsible  for  data  pre-acceptance 
or  translation  to  native  format  A  deliverable  package  that  fails  to  comply  with 
the  contract  requirements  or  is  damaged  is  rejected  and  returned  to  the  contractor. 

7.2  Data  Pre-Acceptance  (P4.2) 

The  deliverable  data  is  imported,  in  CALS  foimat,  to  a  Deliverable  Files  database. 
Data  Pre-Acceptance  may  be  perfonned  at  this  drae  prior  to  translation  or  it  may 
be  omitted  if  the  contract  specifies  data  pre-acceptance  at  the  contractor’s  site.  The 
pre-acceptance  may  be  run  on  a  stand-alone  or  front-end  platform  which  will 
accept  the  delivered  media  directly  for  computer-assisted  format  and  data 
verification  in  a  batch  mode  and  then  deliver  the  verified  data  files  or  media  to 
the  repository  host  computer.  Pre-acceptance  may  also  occur  by  use  of  the 
repository  resources  that  will  accept  or  contain  Data  Pre-Acceptance  software  that 
will  perform  the  image  quality  and  identification  data  verification  in  a  batch  or 
background  mode.  Another  possibility,  for  the  implementation  of  the  computer- 
assisted  data  pre-acceptance  procedures,  would  be  to  import  the  software  to  a 
stand-alone  or  front-end  compatible  platform  that  is  used  for  translation  only. 

See  section  8.0,  Data  Pre-Acceptance,  for  additional  details. 

7.3  Translate  GALS  to  Native  Format  (P4J) 

Upon  satisfactory  completion  of  Data  Pre-Acceptance,  the  accepted  deliverable 
CALS  formatted  files  will  be  translated  to  the  repository’s  native  format.  After 
translation,  the  product  image  and  identification  data  will  be  temporarily  stored, 
in  native  format,  in  the  repository’s  temporary  image  file  database. 

The  oranslarion  process  should  not  degrad.e  the  data  quality.  However,  in  any 
computer  system,  environmental  conditions,  power  failure,  or  other  anomalies  may 
introduce  soft  errors  into  the  data.  It  is  therefore  recommended  that  Final 
Acceptance  sampling  of  tlia  native  data  be  performed. 

7.4  Final  Acceptance  (P4.4) 

The  translated  prcnluct  data  located  in  the  repository  temporary  image  file  database 
must  undergo  visual  inspection  prior  to  loading  into  the  Engineering  Data 
Repository.  This  final  acceptance  of  the  product  data  will  utilize  the  existing 
resources  of  the  repository  for  the  QA  of  image  data. 
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If  full  pre-acceptance  has  been  performed  then  this  visual  acceptance  should  be 
a  sampling  of  the  data  only.  However  this  is  a  contract-specific  option  for  each 
government  user  and  will  depend  on  such  factors  as  the  contractor/user 
performance  history,  volume  of  data  procured,  contractor-site  pre-acceptance 
performed,  user-site  pre-acceptance  performed,  statistical  results  of  the  pre¬ 
acceptance  DA  testing,  and  contract  performance  period. 

Figure  5  shows  that  the  Rejected  Product  Data  will  be  returned  to  the  contractor 
for  resolution.  If  Data  Pre-Acceptance  is  performed  at  the  user  site  then  the 
probability  is  that  the  Final  Acceptance  rejects  will  be  minimal.  It  is 
recommended  that  any  files  rejected  during  Final  Acceptance  be  validated  by 
testing  the  identical  CALS-compliant  file  to  insure  that  the  cause  for  rejection  is 
in  the  contract  deliverable  and  was  not  introduced  in  the  translation  process. 

Satisfactory  Final  Acceptance  will  result  in  completion  of  any  contract  specified 
documentation  such  as  acceptance  reports,  leners  of  acceptance  and  ultimately 
completion  of  DD250s  for  final  acceptance. 

7«5  Return  Contract  Deliverables  (P4.S) 

The  government  user  will  assemble  a  package  of  rejected  contract  deliverables 
which  are  to  be  returned  to  the  contractor.  The  content  of  the  returned 
deliverables  will  depend  on  both  the  rejected  items  and  the  contract  requirements. 
For  example,  in  the  case  of  a  rejected  package  due  to  improper  shipping,  the 
entire  package  will  be  returned  to  the  contractor.  In  the  case  of  one  or  more 
rejected  files  in  a  single  volume,  the  entire  volume  or  the  entire  package  may  be 
returned. 

Product  data  that  must  be  returned  to  the  contractor  must  be  returned  in  the 
CALS-compliant  format  This  means  that  all  product  data  rejected  during  Final 
Acceptance  must  be  inspected  in  the  CALS-compliant  format  as  they  were 
received  from  the  contractor.  Digital  data  provides  alternatives  for  the  handling 
of  rejected  product  data.  If  the  contractor  has  retained  a  CALS-compliant 
deliverable  files  database,  then  the  contract  may  specify  returning  only  a  Data  List 
of  the  rejected  product  data.  The  contractor  can  then  verify  if  the  deliverable  data 
were  defective.  If  the  CALS-compliant  deliverable  files  database  is  not  available, 
then  the  source  native  Product  Data  database  may  be  checked. 
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8.0  DATA  PRE-ACCEPTANCE 

Computer-assisted  data  prc- acceptance  of  product  data  extends  the  ability  of  a 
government  agency  to  ensure  that  all  product  data  received  from  a  conizactor  and 
stored  in  a  repository  is  of  high  quality.  This  is  accomplished  by  the  application 
of  computer-assisted  quality  assurance  techniques  to  inspect  an  entire  image 
database  with  no  human  intervention,  to  find  image  quality  problems,  and  to 
summarize  them  in  a  report.  Qualified  personnel  can  then  review  the  report  and 
visually  inspect  a  sample  of  images  to  confirm  the  results  of  the  automated 
procedures.  The  images  with  reported  problems  can  then  be  visually  inspected  for 
acceptance  or  rejection.  From  the  images  with  no  reported  problems  a  statisticaily 
i  sampled  number  can  be  visually  inspected  to  confirm  that  there  were  no  problems. 
Data  pre-acceptance  is  shown  in  Figure  6. 

Daa  quality  pre-acceptance  of  product  data  is  performed  at  key  points  in  the 
procurement  process.  It  is  site-independent  because  it  can  be  performed  at  the 
contractor  site,  subcontractor  site,  and  the  government  site.  It  is  also  platform- 
independent  because  it  can  be  performed  on  a  repository  system,  a  front-end  to  the 
repository  system,  or  a  stand-alone  system. 

Data  pre-acceptance  is  especially  important  in  inspecting  image  quality  of 
converted  hard  copy  or  aperture  card  data.  An  unacceptable  image  may  be 
generated  from  a  marginaUy-acccptable  source  image.  It  may  have  suffered  quality 
degradation  due  to  age  and  handling.  The  image  scanning  and  generation  process 
may  introduce  noise  which  compounds  that  already  present  in  the  source  image. 

Computer-assisted  techniques  can  be  used  in  data  pre-acceptance  to  achieve  a 
higher  level  of  quality  assurance  than  would  be  possible  solely  by  manual 
handling  and  visual  inspection  of  images.  The  benefit  is  even  more  profound  when 
large  volumes  of  digital  image  data  are  involved  because  computer-assisted 
techniques  can  operate  on  100%  of  the  images.  Visual  inspection  of  large  volumes 
of  images  to  find  poor  quality  images  is  a  labor-intensive  and  error-prone  task. 
The  productivity  of  visual  inspection  can  be  improved  by  focusing  it  to  those 
images  which  were  reponed  to  have  problems  by  computer-assisted  techniques. 
Human  judgement  can  then  be  applied  to  accept  or  reject  them. 

Computer-assisted  techniques  are  applied  to  three  specific  areas  of  interest:  data 
format,  image  quality,  and  image  identification  data. 
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Figure  6  -  Data  Pre -Acceptance 
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8.1  Format  Verification  (PI) 

The  format  of  the  deliverable  files  is  verified  for  compliance  with  MIL-STD- 
1840 A  specifications. 

There  may  be  a  separate  tool  whose  sole  function  is  to  verify  the  format  of  the 
deliverable  files  on  a  magnetic  tape  or  other  CALS-compIiant  media,  to  be 
specified  in  the  future,  and  present  a  comprehensive  repon  of  problems 
encountered. 

However,  the  verification  may  be  only  the  first  step  in  the  translation  done  by 
translation  software.  In  this  case,  the  only  reporting  may  be  a  message  that  the 
translation  cannot  be  done  due  to  an  input  format  error,  a  successful  translation 
would  imply  that  the  input  fonnai  was  in  the  expected  CALS-compliant  format. 

For  physical  media,  the  format  of  the  deliverable  files  can  be  verified  on  the 
deliverable  medium.  For  telecommunications  media,  the  format  of  the  deliverable 
files  can  be  verified  on  the  receiving  system’s  file  system. 

8.2  Image  Quality  Verification  (P2) 

Image  quality  verification  is  a  computer-assisted  technique  which  examines  a 
digitally-stored  image  and  reports  the  quality  of  the  image  with  respect  to  specific 
quality  criteria.  Image  quality  verification  is  primarily  applicable  to  raster  images 
which  were  converted  from  hard  copy  or  aperture  card  source  data. 

Image  quality  may  be  checked  with  respect  to  information  contrast  to  detect 
images  that  are  too  light  or  too  dark.  Image  quality  may  be  checked  with  respect 
to  image- to-image  contrast  range. 

Image  quality  may  also  be  checked  with  respect  to  image  noise.  The  image  file 
is  checked  for  black  and  white  orphans.  An  orphan  is  a  pixel  or  a  small  group  of 
pixels  which  is  completely  surrounded  by  the  contrasting  color.  A  black  orphan 
is  a  dark  orphan  surrounded  by  white  space.  A  white  orphan  is  a  white  speckle  in 
a  filled-in  image  area,  e.g.  a  line,  a  character,  etc.  An  orphan  is  likely  to  represent 
noise  introduced  in  the  image  generation  process  rather  than  image  data. 

Image  quality  may  be  checked  with  respect  to  verticality  to  detect  images  that  are 
skewed.  An  excessively  skewed  drawing  is  likely  to  be  missing  parts  of  an  image 
due  to  cropping  at  the  corners. 
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8^  Image  ID  Data  Verification  (P3) 

Image  ED  Data  Verification  is  a  computer-assisted  technique  which  obtains  ED 
data  from  a  digitally-stored  image,  compares  it  with  the  ID  data  in  the  deliverable 
header,  and  reports  discrepancies  between  the  two.  These  two  may  also  be 
compared  with  a  contractor-furnished  data  list  if  the  contract  specified  that  it  be 
furnished  in  digital  format 

For  raster  images,  the  ED  data  can  be  obtained  from  the  image  file  by  applying 
character  recognition  techniques  to  convert  information  in  the  title  block  area  to 
ASen  text 

For  vector,  i.e.  IGES,  product  data,  the  ED  can  be  obtained  from  the  product  data 
file  directly  by  searching  for  text  which  is  located  in  the  title  block  area. 

8.4  Visual  image  (Quality)  Verification  (P4) 

This  is  a  visual  inspection  of  digital  images  which  will  be  performed  using  a  high- 
resolution  monitor  on  a  graphics  workstation.  The  workstation  may  be  a  part  of 
an  existing  repository  system,  a  part  of  a  front-end  system,  or  a  stand-alone 
system.  The  workstation  used  for  visual  inspection  can  be  a  part  of  the  platform 
used  for  computer-assisted  techniques  or  it  may  be  a  separate  platform. 

The  amount  of  visual  inspection  required  is  dependent  on  the  quality  of  the  digital 
data  provided  by  the  contractor. 

The  government  representative  will  review  the  rejection  report  obtained  from  the 
completion  of  the  batch  analysis  of  the  data  by  the  Image  Quality  and  Image  ID 
Data  Verification  software.  The  government  representative  may  choose  to  now 
look  at  the  rejected  data  as  a  tinal  check. 

The  final  step  in  the  Pre-Acceptance  testing  of  the  deliverable  data  will  be  to 
conduct  a  statistical  sampling  of  the  data  accepted  by  the  computer-assisted  batch 
analysis  process. 

Based  on  the  results  of  the  Visual  Image  Verification,  the  deliverable  data  can  be 
accepted  or  rejected. 
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9.0  CONCLUSIONS 

The  digital  data  acceptance  model  presented,  in  this  document  has  captured  the 
essenni  data  and  process  flow  for  the  generation,  validation  and  acceptance  of 
product  data,  beginning  at  the  contractor  site  and  ending  at  the  government  site. 
As  each  functional  block  in  the  model  is  expanded  in  greater  detail,  the 
implications  and  relationship  among  the  native  image  processing  systems  ^  bOth 
contractor  and  government  sites,  the  CALS  conformance  requirements,  and  the 
computer-assisted  techniques  for  data  quality  assurance  become  evident. 
Computer-assisted  digital  data  acceptance  is  feasible  and  desirable,  but  certain 
adjustments  to  the  existing  manual  data  acceptance  procedures  must  be  made. 
Specifically,  this  model  emphasizes  the  placement  and  execution  Of  data  pre- 
acceptance,  sampling  quality  assurance  and  100%  quality  assurance.  Each  of 
these  functions  be  done  effectively  only  if  the  data  has  been  prepared  in  the 
appropriate  format  and  subjected  to  configuration  controL 

The  model  also  indicates  that  the  data  pre-acceptance  function  will  benefit  the 
most  tom  computer-assisted  techniques.  For  engineering  drawing  digital  data, 
techniques  have  been  identified  for  data  format  verification,  image  quality 
evaluation  and  image  identification  tracking.  The  extent  of  the  applicability  of 
computer-assisted  techniques  to  the  model’s  Data  Pre- Acceptance  process  can  best 
be  determined  by  simulation  and  testing  of  the  techniques.  Simulation  and  testing 
will  also  allow  for  performance  projections  when  dealing  with  large  quantities  of 
data. 
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